Add-on on incident page can't see Incident Id from header anymore

#1

One of our Add-on on Incident stopped working within the last few days because Referer header stopped returning URL with full path (including Incidents, e.g: https://<account-name>.pagerduty.com/incidents/XXXXXXX) and now only returns https://<account-name>.pagerduty.com/

It seems related to Referrer Policy: strict-origin-when-cross-origin header. Utility of Incident page Add-on is very limited if there’s no other options to retrieve Incident Id, or am I missing something?

Thanks,

1 Like
#2

Hello Laurent,

It appears the issue is with the URL being used here. Can you instead use the URL https://api.pagerduty.com as that is were the call is against.

The script below will help drive home what I mean:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>
<script>
// Requires jQuery
var settings = {
 "url": "https://api.pagerduty.com/incidents",
 "method": "GET",
 "headers": {
   "Accept": "application/vnd.pagerduty+json;version=2",
   "Authorization": "Token token=[YOUR TOKEN]"
 }
};

$.ajax(settings).done(function (response) {
 console.log(response);
});
</script>

Cheers

#3

Thanks for your reply Chiedu. Your code snippet shows how to retrieve all incidents via API, not the specific Incident ID from the Incident page that display the Add-on (via the iframe). We were able to retrieve that specific Incident ID via the Referer header until a few days ago. It seems something changed on PagerDuty side.

#4

Hi @LaurentKolakofsky,

We recently implemented this change as a security measure to prevent leakage of customer information outside of PagerDuty.

We have been consulting with our engineering and security teams, and are discussing a possible interim solution that will send the full URL in the Referer header.

However, we will ultimately need to reinstate this Referrer-Policy site-wide and cannot continue leaking full referrer URLs, so are investigating possible workarounds.

1 Like
#5

Hi Laurent,

We have made a change in our system so you should no longer experience the problem you have been for obtaining the incident ID via the Referer header. If you still notice these issues, please let us know.

1 Like
#6

Thanks @demitri @geeth ! Our Add-on works again. We use this Add-on to show previous investigation notes of similar incident so it’s very helpful to our SREs. It would be nice if next time we can be notify ahead of this change with an alternative way to retrieve incident ID so we have time to implement a workaround.

#7

Hi @LaurentKolakofsky,

Your point is noted and will be taken on board.

I do apologise for the inconvenience.

Cheers

#8

Thanks for your quick responses/actions. Great support!

#9

Just to provide an update here and to the rest of the community who may be following:

Last week, we set the referrer policy to no-referrer-when-downgrade, and we plan to keep it this way for the foreseeable future. What this will do is prevent the full URL from being sent by the client (web browser) in the Referer header when following a link or making an in-page HTTP request, if the other site is accessed over a non-secured HTTP protocol. However, it should still work in iframes to URLs that use the HTTPS protocol.

Please feel free to share feedback with us about Add-ons, both your ideal usage of them and how you feel they should be improved! A permanent solution for the issue that arose in this particular use case would be to pass the incident ID to the add-on in some other way, i.e. adding the incident ID into the URL as a parameter. We would ultimately like to tighten the referrer policy in the future without causing this type of issue, and so that would need to involve improving the design of the add-ons feature. Please let us know what you think!

1 Like